Replace the workflow_run chain with a single same-run build graph - #18

Replaces the two chained build workflows with one ci.yml. Net −94 lines.

The actual bug in the old structure

The core and PureData workflows were chained with workflow_run. That trigger checks out the default branch, not the ref that triggered it, while downloading the core artifact from the triggering run. So dispatching the core build on core_modernization made the PureData workflow compile old main sources against a new libzerr_core.a:

undefined reference to `zerr::EnvelopeGenerator::EnvelopeGenerator(
    zerr::SystemConfigs, std::string, std::string)'

— because the constructor had become GenMode-typed. It looked like a real defect. It wasn't. Nothing about that failure was avoidable by configuration; it is what the trigger does.

In ci.yml every job is in one run and wrapper jobs take the core artifact from their own run — no run-id, no github-token, no "Ensure core artifact id present" guard. A cross-commit mix is no longer representable.

Artifacts keyed by toolchain, not platform

This is the part that matters for where the project is going. Windows needs two core builds — MinGW for PureData, and MSVC with static CRT for Max/MSP, since max-pretarget.cmake forces /MT. A single zerr-core-windows artifact cannot express that, so the old structure could never have reached Mac/Linux/Windows × PD/Max/JACK/SuperCollider.

Adding a platform or compiler is one row here plus one row in the consumer job.

Max/MSP gets CI for the first time

On any platform. macOS only for now — Max doesn't exist on Linux (README already marks it ➖), and Windows needs the MSVC/static-CRT path above. Tracked as a follow-up.

Also fixed

• The two workflows resolved dependencies differently on Windows. Core used inline -s compiler=gcc -s compiler.version=13 -s compiler.libcxx=libstdc++11; PureData used -pr:h=profiles/mingw, which also pins cppstd=17, threads=posix, exception=seh. All are package_id inputs, so the two jobs could resolve different binary packages of fftw/yaml-cpp for one logical build — PR Resolve conan dependencies once at the repo root #13's single-resolve invariant, broken at the CI layer. Both now take the profile from the same matrix row.
• Composite setup-deps action replaces the conan block duplicated 6×, and caches ~/.conan2. fftw and yaml-cpp currently build from source on macOS and Windows every run — most of the Windows job's 3m41s on Run the core build on pull requests #17.
• Path filters dropped. A core change must rebuild every wrapper; a wrapper-only change must still build. The old filters are why a puredata/- or maxmsp/-only change triggered nothing at all.
• concurrency group cancels superseded runs; checkout@v3 → @v4 (v3 targets deprecated Node 20).

deploy-doxygen.yml is untouched — it fails by design pending the org owner, per docs/design/github-pages-deployment.md.

Review notes

This PR validates itself. Thanks to #17 the checks run here, so what you see below is the verification. Worth watching:

1. core ×3 → puredata ×3 + maxmsp ×1, wrappers starting only after core.
2. puredata (windows-mingw) is the job that matters most — the only one that can catch core/wrapper API drift at build time. macOS links externals with -undefined suppress and Linux permits undefined symbols in a .so, so both would happily produce an external that fails at load.
3. Known risk: the Windows core job now uses profiles/mingw, whose compiler_executables pins the x86_64-w64-mingw32-* names, and whose compiler.version=13 no longer matches the runners' gcc 16.1.0. The old inline settings sidestepped both. If this fails, the fix is to drop the compiler_executables pin or add a native profile — and we find out here rather than on main, which is exactly why Run the core build on pull requests #17 went first.

🤖 Generated with Claude Code